Add patch release notes and docs fixes #1412
Conversation
coruscating
added
backport stable potential
| .. jupyter-execute:: | ||
| :hide-code: | ||
| :hide-output: | ||
|
|
||
| %matplotlib inline | ||
|
|
There was a problem hiding this comment.
Not sure why, but removing this block got rid of the RuntimeWarning: divide by zero encountered in det numpy errors for me locally. The block also doesn't do anything to begin with since the figures already render fine.
There was a problem hiding this comment.
Looks good.
I think we should move to building the release notes for the previous minor with reno report and adding that output directly into release_notes.rst when we make a new minor release and then only use the release-notes:: directive for the current minor. The reason that 0.3.1 does not show up is that it is not in the history of stable/0.5 since 0.3 branched off from main and 0.3.1 was on that branch. Basically, we will only get one release worth of patch notes per release.
We could do
.. release-notes::
:branch: stable/0.5
:earlieast-version: 0.5.0
.. release-notes::
:branch: stable/0.4
:earlieast-version: 0.4.0
.. release-notes::
:branch: stable/0.3
:earlieast-version: 0.3.0
.. release-notes::
:branch: stable/0.2
:earlieast-version: 0.2.0
but I don't see the advantage to continuing to build the old notes from the individual files when those releases are never changing. If a Sphinx reference breaks, we have to go back and fix it in the old branch. I think it's better just to keep the rendered rst in the file and update it on the main branch if we need to.
I agree that deleting the patch release notes from the main branch is necessary. With the way we do things now, I think we could do this with a script. When a new minor 0.X.0 is going to be released, we move all the files in releasenotes/notes into release/notes/0.X. Then after the release is branched, any new notes get added to releasenotes/notes (which starts the release empty) and any backported ones get copied to releasenotes/notes on stable/0.X. So when it is time to release 0.(X+1).0, we just need a script to get the list of files in releasenotes/notes on stable/0.X and remove them from releasenotes/notes on main.
| .. jupyter-execute:: | ||
| :hide-code: | ||
| :hide-output: | ||
|
|
||
| %matplotlib inline | ||
|
|
### Summary Closes #1401. Our release notes currently doesn't include notes of the patch releases before the most recent minor release. This PR updates `release_notes.rst` to build previous patch releases (0.3.1 isn't rendering but I think it's too old to be useful now anyways). The new process prior to release is that release notes from the most recent minor version's patch releases should be deleted from the main branch prior to a new minor release, and `release_notes.rst` needs to have a new directive added for the previous stable branch. ### Details and comments A few other minor changes: - Wraps the output text of jupyter-sphinx blocks - Update the contributor guide to include release note subcategories - Suppress the debugger warning during the docs build by setting `PYDEVD_DISABLE_FILE_VALIDATION=1` - Add a link to the main branch to the dev docs banner - (cherry picked from commit 0bbd426)
This is an automatic backport of pull request #1412 done by [Mergify](https://mergify.com). --- <details> <summary>Mergify commands and options</summary> <br /> More conditions and actions can be found in the [documentation](https://docs.mergify.com/). You can also trigger Mergify actions by commenting on this pull request: - `@Mergifyio refresh` will re-evaluate the rules - `@Mergifyio rebase` will rebase this PR on its base branch - `@Mergifyio update` will merge the base branch into this PR - `@Mergifyio backport <destination>` will backport this PR on `<destination>` branch Additionally, on Mergify [dashboard](https://dashboard.mergify.com) you can: - look at your merge queues - generate the Mergify configuration with the config editor. Finally, you can contact us on https://mergify.com </details> Co-authored-by: Helena Zhang <[email protected]>
|
I just noticed the notes in the github build only goes back to the 0.4 prelude, which I didn't catch because my local build went back to 0.2: https://qiskit-extensions.github.io/qiskit-experiments/dev/release_notes.html. In the logs, reno only saw 0.5.x and 0.4 in stable/0.5, maybe because it doesn't know about the older tags? I suppose we may as well put in a PR to backfill the old notes manually since we want to do that anyways. |
### Summary As described in #1412 (review), this PR removes the directive for older release notes to prep for the 0.6.1 patch release. Avoiding rebuilding older release notes every time also removes the requirement for local builds to fetch older stable branches. Older patch release notes that were missing, such as 0.3.1, have been repopulated. The reno version has also been updated to the newest release instead of the previous commit ID.
### Summary As described in #1412 (review), this PR removes the directive for older release notes to prep for the 0.6.1 patch release. Avoiding rebuilding older release notes every time also removes the requirement for local builds to fetch older stable branches. Older patch release notes that were missing, such as 0.3.1, have been repopulated. The reno version has also been updated to the newest release instead of the previous commit ID. (cherry picked from commit 4c93833)
### Summary As described in #1412 (review), this PR removes the directive for older release notes to prep for the 0.6.1 patch release. Avoiding rebuilding older release notes every time also removes the requirement for local builds to fetch older stable branches. Older patch release notes that were missing, such as 0.3.1, have been repopulated. The reno version has also been updated to the newest release instead of the previous commit ID.<hr>This is an automatic backport of pull request #1437 done by [Mergify](https://mergify.com). Co-authored-by: Helena Zhang <[email protected]>
Summary
Closes #1401. Our release notes currently doesn't include notes of the patch releases before the most recent minor release. This PR updates
release_notes.rstto build previous patch releases (0.3.1 isn't rendering but I think it's too old to be useful now anyways). The new process prior to release is that release notes from the most recent minor version's patch releases should be deleted from the main branch prior to a new minor release, andrelease_notes.rstneeds to have a new directive added for the previous stable branch.Details and comments
A few other minor changes:
PYDEVD_DISABLE_FILE_VALIDATION=1